Transaction processing
The concept of a transaction is an important programming paradigm for simplifying the construction of reliable application programs, especially those that require concurrent access to shared data. The business function of a commercial application program typically involves processing many similar items, for example orders in an order processing system or seat reservations in an airline booking system. The processing of one of these items (i.e. the execution of this discrete unit of processing) is a transaction. A sequence of associated operations which transforms a consistent state of a recoverable resource into another consistent state is known as a "unit of work". A unit of work must either be fully completed (and committed at completion of the transaction) or fully purged without action (rolled back). When a transaction is committed, all changes made by the associated requests are made permanent. Transaction processing is the management of discrete units of work that access and update shared data. A transaction may comprise one or many units of work and may be distributed across a data processing network. Distributed transaction processing involves a transaction that affects resources at more than one physical or logical location.
In a typical transaction processing environment, many users repeatedly process similar transactions. Transaction processing is particularly effective for the processing of unscheduled single items in unpredictable volumes and sequence, for changing enterprise data to reflect updates as they are processed, and for providing immediate on-line access to enterprise data that has been updated to reflect all previous transactions.
The following basic functions and characteristics are usually required of transaction processing systems:
On-line processing (for which a user needs a terminal or workstation connected to the system); PA1 High availability (i.e. the system must be available for processing when needed--this requires automated recovery from failures and minimised impact from scheduled outages such as upgrades and database backups); PA1 Rapid response time (to avoid users repeatedly waiting--this will typically involve prioritising and workload balancing); PA1 Low cost per transaction and efficient throughput; PA1 Access to and update of shared resources with integrity (see below). PA1 1. the name of the class; PA1 2. the operations (methods) for manipulating the instances (objects) of the class; PA1 3. the internal implementation of the interface of the objects; PA1 4. the internal representation of objects. PA1 1. constructing reusable software components and easily extensible libraries of software modules. PA1 2. easily modifying and extending implementations of components without having to recode everything from scratch. PA1 3. modelling the real world as close to a user's perspective as possible. PA1 4. interacting easily with a computational environment.
The last mentioned function is particularly important. Very large numbers of transactions may read or cause changes to an enterprise's data store. It is important that transactions read valid data and that their updates are correctly recorded. Ensuring this is called maintaining data integrity. To preserve full data integrity, a transaction processing system and its applications must combine to ensure that each transaction has the four "ACID" properties of atomicity, consistency, isolation, and durability. How this is achieved depends on the specific transactional model implemented.
Two types of transaction processing system are known: systems including an independent transaction processing (TP) manager which runs on an operating system platform, and integrated systems in which a TP manager is built into an operating system. Independent and integrated systems are shown in FIGS. 1A and 1B respectively. Referring to FIG. 1A, an independent TP manager 10 needs interfaces to the operating system 20 and to a database management system 30, as well as providing a platform for transactional application programs 40. For integrated systems such as shown in FIG. 1B, the transaction processing manager 10' and usually also the database manager 30' are built into the operating system 20' so that the only external interface required is to the application programs 40. Application programming interfaces (APIs) 50 enable a transaction application program 40 to use the services of the transaction processing manager--services such as communications, presentation, data access and commitment control.
Further general information on transaction processing can be found in the book "Transaction Processing: Concepts and Products" (IBM document number GC33-0754-00), which is available from IBM.
A number of different transaction processing models are known in the art. Some transaction processing systems require explicit transactional demarcation--i.e. an application program must issue the relevant API commands for operations to begin, commit or rollback a transaction. This requirement is a feature of the Object Management Group, Inc.'s (OMG's) Object Transaction Service (OTS) specification--a specification for a proposed service which supports transactional behaviour in a distributed heterogeneous environment based on the OMG Common Object Request Broker Architecture (CORBA). CORBA defines the interactions between objects of an object oriented system (see below), and in particular between distributed objects in different systems. The OTS exploits object oriented programming to encapsulate the processing performed under transactional scope, allowing a programmer (or similar person) to designate certain classes of operations as transactional. The unchained model of transactions is supported since a client program can explicitly start, suspend and resume transactions. Invoking a transactional operation outside a transaction causes the operation to be performed outside the scope of any transaction. In the unchained model, a program can explicitly enter and leave the scope of transactions so that some of its execution might be within the scope of one transaction, some within the scope of another, and some outside the scope of any transaction. Unlike the non-object-oriented unchained model, in which a program can freely mix transactional and non-transactional work, OTS requires that the transactional operations be distinctly marked.
Other transaction processing systems coordinate the delimiting of transactions (e.g. commit processing) themselves, so as to ensure that the system can reliably deal with recovery in the event of a failure during processing of the transaction. The CICS on-line transaction processing programs, which are commercially available from International Business Machines Corporation, support "chained" transactions across cooperating systems. Chained transactions have the property that a program (e.g. a CICS application) is always within the scope of some transaction, and a system that implements the chained model can maintain the rule that all transactional operations must be executed under its control (by means of transaction programs in the case of CICS systems). A CICS transaction begun in one system may include operations performed by other systems, with demarcation of the transaction (e.g. commit processing) being controlled by a CICS system without requiring application-initiated demarcation operations. CICS systems do have provision for an application program to specify intermediate syncpoints as wanted, which additional delimiting of units of work can enhance recovery, but this is not an essential feature of the CICS transactional model. CICS is a trade mark of International Business Machines Corporation.
It is an important distinction between the CICS transactional model and the OTS transactional model that CICS servers manage units of work and support chained transactions whereas OTS requires client application control and implements an unchained transaction model, since the respective transactions look very different, and require different action, from the client application. This mismatch between the transactional models currently prevents interoperation between data processing resources which implement the different models.
It is thus a requirement of the prior art that, if a plurality of data processing resources within a network are to be involved in the performance of operations within a specific distributed transaction, then those data processing resources must all implement the same model of a transaction. This causes problems for organisations wishing to supplement their existing resources with resources which are based on a different model of transaction processing, or who acquire or merge with other organisations having such resources, or who wish to extend their network of computing resources to include suppliers, business partners or customers in an inter-enterprise network. Organisations increasingly need their application programs to operate across distributed heterogeneous networks, which necessitates interoperation between those data processing resources which implement different transactional models.
Object Oriented Computing
An area of significant recent development in the computing industry is the development of object-oriented (OO) computing. While the above mentioned transaction paradigm is essential to developing reliable distributed applications, the object paradigm of OO computing is key to achieving high productivity and quality in application development. Object-oriented (OO) programs differ from traditional computer programs (which are structured sequences of calculations and logic that access data) in that the data and their related calculations are grouped together. An "object" is a self-contained software package (e.g. a component, or module) which combines variables (data, attributes) and methods (procedures, processes, routines, operations) that operate on those variables to perform a specialized role (function) in a system. Methods are embedded within objects and do not operate as free-standing entities. Objects are autonomous entities and the object's data can only be manipulated by that object using the defined methods. This is known as "encapsulation". An object is defined via its "class", and is an instance of the class.
A class is a software template that defines the form of sets of similar objects. A class defines the structure of a set of objects or instances. A class also specifies the methods that define the behaviour of its instances. A class definition includes:
Object orientation provides paradigms and tools for:
In OO programming, problems to be solved are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures. Object orientation provides a programming style that allows efficient organization and modularization (i.e. separation of function) of large application programs. These advantages to programming style can be achieved using OO concepts and ideas even without using special OO languages, but a number of OO languages have evolved and other procedural or functional languages have been extended to include object oriented constructs. C++ is an example of one such OO-extended language which supports class hierarchies and allows subclasses to access methods and instance variables from other classes in the hierarchy.
Because of the advantages of object orientation which are mentioned above, object oriented technologies, together with recent advanced transactional concepts, are achieving widespread acceptance in the computing industry. Many organisations are recognising the advantages of targetting future investment so as to migrate from their existing data processing resources towards resources which enable the exploitation of these advanced transactional and object-oriented concepts. However, despite the benefits of such migration, it is also essential to many companies to continue to fully utilise their existing resources as they manage the migration--a company's existing stocks of computing resources may include applications, data and infrastructure built up over many years and with large capital investment.
Thus, there is firstly a requirement for systems and methods which enable interoperation between computing resources which implement different transaction processing models. In particular, it is also desirable to enable use of object-oriented programming techniques within transactional systems without sacrificing existing non-object-oriented applications, infrastructure and data. Furthermore, it is desirable to enable transactions to be controlled using consistent operations across multiple transaction services.
Copending U.S. patent application Ser. No. 08/320,357 (filed 11 Oct. 1994) describes the provision of interoperation between an object oriented transaction service and procedural transaction coordinators using a set of object classes. Although recognising that the implementation classes required to achieve such interoperation will necessarily be different for different transaction coordinators, U.S. Ser. No. 08/320,357 does not disclose a solution to the specific problem of mismatch between the chained and unchained models, where transactional operations according to one model do not have a corresponding operation within the scope of a transaction according to the second model.
IBM Technical Disclosure Bulletin vol.38, No.3, March 1995, pages 617-620, discloses the desirability of interoperation between OTS and a Resource Manager implementing the X/Open Distributed Transaction Processing (DTP) model. Described is a mapping between operations of the XA interface (defined by the DTP model) and OTS two-phase commit operations, using a subclass of the OMG Resource Class (called XAResource) and an object which creates XAResource objects and registers them with a transaction coordinator. There is no disclosure of the problem of mismatch between chained and unchained models of a transaction.